home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 3 / QRZ Ham Radio Callsign Database - Volume 3.iso / digests / tcp / 930080.txt < prev    next >
Internet Message Format  |  1994-06-04  |  35KB
  1. Date: Sun, 28 Mar 93 04:30:11 PST
  2. From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
  3. Errors-To: TCP-Group-Errors@UCSD.Edu
  4. Reply-To: TCP-Group@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: TCP-Group Digest V93 #80
  7. To: tcp-group-digest
  8.  
  9.  
  10. TCP-Group Digest            Sun, 28 Mar 93       Volume 93 : Issue   80
  11.  
  12. Today's Topics:
  13.                     Ftpmotd in jnos v108d (2 msgs)
  14.                          G8BPQ with IP Router
  15.                     KA9Q NOS questions... (2 msgs)
  16.                   TCP-Group Digest V93 #79 (2 msgs)
  17.  
  18. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  19. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  20. Problems you can't solve otherwise to brian@ucsd.edu.
  21.  
  22. Archives of past issues of the TCP-Group Digest are available
  23. (by FTP only) from UCSD.Edu in directory "mailarchives".
  24.  
  25. We trust that readers are intelligent enough to realize that all text
  26. herein consists of personal comments and does not represent the official
  27. policies or positions of any party.  Your mileage may vary.  So there.
  28. ----------------------------------------------------------------------
  29.  
  30. Date: Sat, 27 Mar 93 17:43:49 EST
  31. From: Steve Urich <beyonet!steve@gvls1.VFL.Paramax.COM>
  32. Subject: Ftpmotd in jnos v108d
  33. To: TCP-Group@ucsd.edu
  34.  
  35.  Hello, for those of you who are interested I have changed the
  36.  ftpmotd in jnos ftpserv to conform to internet standards. I
  37.  have put the motd in my version of net and also in a version
  38.  of pa0gri. It works with most of the original ka9q ftpcli 
  39.  including net and most nos except the jnos client with has
  40.  a verbose default problem that somebody changed. I sent my
  41.  changes to Johan and explained the problem. Its due to the
  42.  client remaining quiet till a remote command is ordered
  43.  giving it a V_NORMAL verbose. Then the ftpmotd gets shown
  44.  when a data port is able to be read verbose. It works normal
  45.  with net and other versions of nos clients showing the motd
  46.  at 230 AFTER the login as it should be. I mainly changed the
  47.  motd routine and added it also to my server because of the
  48.  way it was sent out at 220 breaking my ka9q net client. Since
  49.  I don't have a dos box to compile jnos I can't fix the jnos
  50.  client myself without some debugging since the initial test
  51.  with wa3dsp Doug has proven to be ok with my client by a
  52.  slight difference in the jnos client because of its verbose.
  53.  Since I can't debug and compile jnos because I don't have
  54.  a dos box I had wa3dsp compile it for me. It worked ok for
  55.  me but the jnos client was coded differently then the vanilla
  56.  client code. It looks easy enough to debug if I had a dos
  57.  machine an compiler. Here are the diffs to the change from
  58.  220 to 230 for the motd.
  59.  
  60.  73 - Steve
  61.  
  62. ----Start `diff -c' ftpserv.c v1.08d----
  63. *** ftpserv.old Wed Mar 24 18:20:45 1993
  64. --- ftpserv.new Fri Mar 26 01:26:59 1993
  65. ***************
  66. *** 55,62
  67.   };
  68.   
  69.   /* Response messages */
  70. ! static char banner[] = "220- %s, KA9Q-NOS FTP version %s\n";
  71. ! static char banner1[] = "220  Ready on %s";
  72.   static char badcmd[] = "500 Unknown command\n";
  73.   static char binwarn[] = "100 Warning: type is ASCII and %s appears to be binary\n";
  74.   static char unsupp[] = "500 Unsupported command or option\n";
  75.  
  76. --- 55,62 -----
  77.   };
  78.   
  79.   /* Response messages */
  80. ! static char banner[] = "220 %s, KA9Q-NOS FTP version %s\n";
  81. ! static char banner1[] = "230  Ready on %s";
  82.   static char badcmd[] = "500 Unknown command\n";
  83.   static char binwarn[] = "100 Warning: type is ASCII and %s appears to be binary\n";
  84.   static char unsupp[] = "500 Unsupported command or option\n";
  85. ***************
  86. *** 173,179
  87.    long t;
  88.    int cnt,i;
  89.    struct sockaddr_in socket;
  90. -     FILE *fp;
  91.   
  92.    sockmode(s,SOCK_ASCII);
  93.    memset((char *)&ftp,0,sizeof(ftp));     /* Start with clear slate */
  94.  
  95. --- 173,178 -----
  96.    long t;
  97.    int cnt,i;
  98.    struct sockaddr_in socket;
  99.   
  100.    sockmode(s,SOCK_ASCII);
  101.    memset((char *)&ftp,0,sizeof(ftp));     /* Start with clear slate */
  102. ***************
  103. *** 197,209
  104.   
  105.    log(s,"open FTP");
  106.    usprintf(s,banner,Hostname,Version);
  107. -     if((fp = fopen(Ftpmotd,"r")) != NULL) {
  108. -         while(fgets(buf,128,fp)) {
  109. -             rip(buf);
  110. -             usprintf(s,"220- %s\n",buf);
  111. -         }
  112. -         fclose(fp);
  113. -     }
  114.    time(&t);
  115.    cp = ctime(&t);
  116.    
  117.  
  118. --- 196,201 -----
  119.   
  120.    log(s,"open FTP");
  121.    usprintf(s,banner,Hostname,Version);
  122.    time(&t);
  123.    cp = ctime(&t);
  124.    
  125. ***************
  126. *** 211,218
  127.       if((cp1 = strchr(cp,'\n')) != NULLCHAR)
  128.    *cp1 = '\0';
  129.   #endif
  130. -  
  131. -  usprintf(s,banner1,cp);
  132.   
  133.   loop:   if((cnt = recvline(s,buf,sizeof(buf))) == -1){
  134.     /* He closed on us */
  135.  
  136. --- 203,208 -----
  137.       if((cp1 = strchr(cp,'\n')) != NULLCHAR)
  138.    *cp1 = '\0';
  139.   #endif
  140.   
  141.   loop:   if((cnt = recvline(s,buf,sizeof(buf))) == -1){
  142.     /* He closed on us */
  143. ***************
  144. *** 568,574
  145.   struct ftpserv *ftp;
  146.   char *pass;
  147.   {
  148. !  char *path;
  149.    char *p;
  150.    int anony = 0;
  151.   
  152.  
  153. --- 558,564 -----
  154.   struct ftpserv *ftp;
  155.   char *pass;
  156.   {
  157. !  char *path,buf[128],*cp;
  158.    char *p;
  159.    long t;
  160.    FILE *fp;
  161. ***************
  162. *** 570,575
  163.   {
  164.    char *path;
  165.    char *p;
  166.    int anony = 0;
  167.   
  168.    path = mallocw(200);
  169.  
  170. --- 560,567 -----
  171.   {
  172.    char *path,buf[128],*cp;
  173.    char *p;
  174. +  long t;
  175. +  FILE *fp;
  176.    int anony = 0;
  177.   
  178.    path = mallocw(200);
  179. ***************
  180. *** 590,595
  181.    if((p = strchr(path,';')) != '\0')
  182.     *p = '\0';              /* delimit initial cd */
  183.   #endif
  184.   
  185.    if(!anony){
  186.     usprintf(ftp->control,logged);
  187.  
  188. --- 582,598 -----
  189.    if((p = strchr(path,';')) != '\0')
  190.     *p = '\0';              /* delimit initial cd */
  191.   #endif
  192. +  time(&t);
  193. +  cp = ctime(&t);
  194. +  usprintf(ftp->control,banner1,cp);
  195. + 
  196. +     if((fp = fopen(Ftpmotd,"r")) != NULL) {
  197. +         while(fgets(buf,sizeof(buf),fp)) {
  198. +             rip(buf);
  199. +             usprintf(ftp->control,"230- %s\n",buf);
  200. +         }
  201. +         fclose(fp);
  202. +     }
  203.   
  204.    if(!anony){
  205.     usprintf(ftp->control,logged);
  206. ---End of diff cut here---
  207.  
  208.  
  209. -- 
  210. |Stephen Urich|        Internet:steve@zero.com         | "Cattle mutilations |
  211. |NIC: SU2     |        UUCP:uunet!beyonet!steve        | are up!" --Sneakers |
  212. |ARS: WB3FTP  | Packet:WB3FTP@WB3FTP.#EPA.PA.USA.NOAM  | ax25<->PBBS<->IPGATE|
  213. |Bensalem, PA |Radio:wb3ftp@wb3ftp.ampr.org[44.80.8.44]| TCP/IP-FTP-SMTP-UNIX|
  214.  
  215. ------------------------------
  216.  
  217. Date: Sat, 27 Mar 93 17:43:49 EST
  218. From: Steve Urich <beyonet!steve@gvls1.VFL.Paramax.COM>
  219. Subject: Ftpmotd in jnos v108d
  220. To: TCP-Group@ucsd.edu
  221.  
  222.  Hello, for those of you who are interested I have changed the
  223.  ftpmotd in jnos ftpserv to conform to internet standards. I
  224.  have put the motd in my version of net and also in a version
  225.  of pa0gri. It works with most of the original ka9q ftpcli 
  226.  including net and most nos except the jnos client with has
  227.  a verbose default problem that somebody changed. I sent my
  228.  changes to Johan and explained the problem. Its due to the
  229.  client remaining quiet till a remote command is ordered
  230.  giving it a V_NORMAL verbose. Then the ftpmotd gets shown
  231.  when a data port is able to be read verbose. It works normal
  232.  with net and other versions of nos clients showing the motd
  233.  at 230 AFTER the login as it should be. I mainly changed the
  234.  motd routine and added it also to my server because of the
  235.  way it was sent out at 220 breaking my ka9q net client. Since
  236.  I don't have a dos box to compile jnos I can't fix the jnos
  237.  client myself without some debugging since the initial test
  238.  with wa3dsp Doug has proven to be ok with my client by a
  239.  slight difference in the jnos client because of its verbose.
  240.  Since I can't debug and compile jnos because I don't have
  241.  a dos box I had wa3dsp compile it for me. It worked ok for
  242.  me but the jnos client was coded differently then the vanilla
  243.  client code. It looks easy enough to debug if I had a dos
  244.  machine an compiler. Here are the diffs to the change from
  245.  220 to 230 for the motd.
  246.  
  247.  73 - Steve
  248.  
  249. ----Start `diff -c' ftpserv.c v1.08d----
  250. *** ftpserv.old Wed Mar 24 18:20:45 1993
  251. --- ftpserv.new Fri Mar 26 01:26:59 1993
  252. ***************
  253. *** 55,62
  254.   };
  255.   
  256.   /* Response messages */
  257. ! static char banner[] = "220- %s, KA9Q-NOS FTP version %s\n";
  258. ! static char banner1[] = "220  Ready on %s";
  259.   static char badcmd[] = "500 Unknown command\n";
  260.   static char binwarn[] = "100 Warning: type is ASCII and %s appears to be binary\n";
  261.   static char unsupp[] = "500 Unsupported command or option\n";
  262.  
  263. --- 55,62 -----
  264.   };
  265.   
  266.   /* Response messages */
  267. ! static char banner[] = "220 %s, KA9Q-NOS FTP version %s\n";
  268. ! static char banner1[] = "230  Ready on %s";
  269.   static char badcmd[] = "500 Unknown command\n";
  270.   static char binwarn[] = "100 Warning: type is ASCII and %s appears to be binary\n";
  271.   static char unsupp[] = "500 Unsupported command or option\n";
  272. ***************
  273. *** 173,179
  274.    long t;
  275.    int cnt,i;
  276.    struct sockaddr_in socket;
  277. -     FILE *fp;
  278.   
  279.    sockmode(s,SOCK_ASCII);
  280.    memset((char *)&ftp,0,sizeof(ftp));     /* Start with clear slate */
  281.  
  282. --- 173,178 -----
  283.    long t;
  284.    int cnt,i;
  285.    struct sockaddr_in socket;
  286.   
  287.    sockmode(s,SOCK_ASCII);
  288.    memset((char *)&ftp,0,sizeof(ftp));     /* Start with clear slate */
  289. ***************
  290. *** 197,209
  291.   
  292.    log(s,"open FTP");
  293.    usprintf(s,banner,Hostname,Version);
  294. -     if((fp = fopen(Ftpmotd,"r")) != NULL) {
  295. -         while(fgets(buf,128,fp)) {
  296. -             rip(buf);
  297. -             usprintf(s,"220- %s\n",buf);
  298. -         }
  299. -         fclose(fp);
  300. -     }
  301.    time(&t);
  302.    cp = ctime(&t);
  303.    
  304.  
  305. --- 196,201 -----
  306.   
  307.    log(s,"open FTP");
  308.    usprintf(s,banner,Hostname,Version);
  309.    time(&t);
  310.    cp = ctime(&t);
  311.    
  312. ***************
  313. *** 211,218
  314.       if((cp1 = strchr(cp,'\n')) != NULLCHAR)
  315.    *cp1 = '\0';
  316.   #endif
  317. -  
  318. -  usprintf(s,banner1,cp);
  319.   
  320.   loop:   if((cnt = recvline(s,buf,sizeof(buf))) == -1){
  321.     /* He closed on us */
  322.  
  323. --- 203,208 -----
  324.       if((cp1 = strchr(cp,'\n')) != NULLCHAR)
  325.    *cp1 = '\0';
  326.   #endif
  327.   
  328.   loop:   if((cnt = recvline(s,buf,sizeof(buf))) == -1){
  329.     /* He closed on us */
  330. ***************
  331. *** 568,574
  332.   struct ftpserv *ftp;
  333.   char *pass;
  334.   {
  335. !  char *path;
  336.    char *p;
  337.    int anony = 0;
  338.   
  339.  
  340. --- 558,564 -----
  341.   struct ftpserv *ftp;
  342.   char *pass;
  343.   {
  344. !  char *path,buf[128],*cp;
  345.    char *p;
  346.    long t;
  347.    FILE *fp;
  348. ***************
  349. *** 570,575
  350.   {
  351.    char *path;
  352.    char *p;
  353.    int anony = 0;
  354.   
  355.    path = mallocw(200);
  356.  
  357. --- 560,567 -----
  358.   {
  359.    char *path,buf[128],*cp;
  360.    char *p;
  361. +  long t;
  362. +  FILE *fp;
  363.    int anony = 0;
  364.   
  365.    path = mallocw(200);
  366. ***************
  367. *** 590,595
  368.    if((p = strchr(path,';')) != '\0')
  369.     *p = '\0';              /* delimit initial cd */
  370.   #endif
  371.   
  372.    if(!anony){
  373.     usprintf(ftp->control,logged);
  374.  
  375. --- 582,598 -----
  376.    if((p = strchr(path,';')) != '\0')
  377.     *p = '\0';              /* delimit initial cd */
  378.   #endif
  379. +  time(&t);
  380. +  cp = ctime(&t);
  381. +  usprintf(ftp->control,banner1,cp);
  382. + 
  383. +     if((fp = fopen(Ftpmotd,"r")) != NULL) {
  384. +         while(fgets(buf,sizeof(buf),fp)) {
  385. +             rip(buf);
  386. +             usprintf(ftp->control,"230- %s\n",buf);
  387. +         }
  388. +         fclose(fp);
  389. +     }
  390.   
  391.    if(!anony){
  392.     usprintf(ftp->control,logged);
  393. ---End of diff cut here---
  394.  
  395.  
  396. -- 
  397. |Stephen Urich|        Internet:steve@zero.com         | "Cattle mutilations |
  398. |NIC: SU2     |        UUCP:uunet!beyonet!steve        | are up!" --Sneakers |
  399. |ARS: WB3FTP  | Packet:WB3FTP@WB3FTP.#EPA.PA.USA.NOAM  | ax25<->PBBS<->IPGATE|
  400. |Bensalem, PA |Radio:wb3ftp@wb3ftp.ampr.org[44.80.8.44]| TCP/IP-FTP-SMTP-UNIX|
  401.  
  402. ------------------------------
  403.  
  404. Date: Sun, 28 Mar 93 09:00:50 GMT
  405. From: g4klx@g4klx.demon.co.uk (Jonathan Naylor)
  406. Subject: G8BPQ with IP Router
  407. To: TCP-Group@ucsd.edu
  408.  
  409. Hi All
  410.  
  411. I put BPQ406E.ZIP into the wrong incoming directory. It is now in
  412. /hamradio/packet/tcpip/incoming.
  413.  
  414. Sorry
  415.  
  416. Jonathan
  417.  
  418. ------------------------------
  419.  
  420. Date: Sat, 27 Mar 1993 11:41:17 -0600 (CST)
  421. From: gerry@cs.tamu.edu (Gerald J Creager)
  422. Subject: KA9Q NOS questions...
  423. To: tcp-group@ucsd.edu
  424.  
  425.  I recently shipped this to the group, but I've seen neither the question, nor
  426.  any responses, so I guess it went to a bit bucket in the sky... Let's try
  427.  again.
  428.  
  429. I recently downloaded Phil's latest from ucsd.edu.  I tried to bring it up
  430. initially with an autoexec.nos configured for jnos 107b.  With the exception of
  431. the attach asy statement, I have changed nothing, but I'm seeing some
  432. interesting anomolies and NEED some help.
  433.  
  434. 1.  Hardware config:
  435. '386DX/'387, 4 Mb memory, 130 Mb hard disk, 3 Mb free on NOS logical drive, 6
  436. Mb free on a separate logical drive for /temp.
  437.  
  438. 2.  Software Config:
  439. QEMM/386, ansi.sys, the world loaded high, 633k available.
  440.  
  441. 3.  TNC config:
  442. PacComm Tiny-2 with "node" (higher speed) parts, port speed 9600 baud, radio
  443. speed 1200 baud, ROM rev. 1.1.6b (PacComm)
  444.  
  445. 4.  Recent history:
  446. Works "fine" with jnos, older karncode (tm) and g1emmCode (tm).  Worked fine at
  447. higher radio rates with DataEngine testing last year.
  448.  
  449. 5.  Symptoms:
  450.  
  451. A.  When I issue *ANY* sort of transmission, with trace turned on, I see an
  452. ax.25 "bad header" message in trace.
  453.  
  454. B.  Occassionally, say, <10% of the time, I see what looks to the code
  455. (appparently) like a good ax.25 packet but is gibberish.
  456.  
  457. C.  Other systems see the packets I'm pumping out, and they look normal to
  458. them.  A connect request using either native ax.25 or tcp/ip results in the
  459. other system thinking it can really talk to me, but I cannot make sense of the
  460. replys.
  461.  
  462. I have used both the ax25ui and ax25i constructs in the attaach asy command
  463. line, with similar results.  Since I haven't pulled down the source yet, I have
  464. no "documentation" to work with...  I need more disk space, and I'm working oin
  465. that issue.
  466.  
  467. Anyone got thoughts?  I was wondering if KISS wasn't compiled into the code,
  468. possibly...  If that's the case, I guess I need to learn something about RCS
  469. and grab a copy of Borland C++ 3.x...
  470.  
  471. Thanks,
  472. Gerry  n5jxs
  473. gerry@cs.tamu.edu
  474.  
  475. ------------------------------
  476.  
  477. Date: Sat, 27 Mar 93 17:01:07 EST
  478. From: Mike Gallaher <mg@bds.bds.com>
  479. Subject: KA9Q NOS questions...
  480. To: gerry@cs.tamu.edu (Gerald J Creager)
  481.  
  482. Try using "kissui" or "kissi" instead of "ax25ui"/"ax25i".
  483. If you use ax25 encapsulation, it just sends raw ax25 packets to the
  484. serial port, assuming that whatever hears them will transmit them
  485. literally (like an 8530 card).  If you use kiss encapsulation, it
  486. prepends a kiss "data follows" byte to the ax25 packet; this is
  487. what the TNC expects, to distinguish data from parameter-setting commands,
  488. for instance.  At least, that's what I've been able to glean from
  489. looking at the source, and playing with it for a few minutes.
  490. I haven't seen any documentation either.
  491.  
  492. mg
  493.  
  494. ------------------------------
  495.  
  496. Date: Sat, 27 Mar 93 15:05:15 EST
  497. From: Postmaster@alis3.daytonoh.ncr.com
  498. Subject: TCP-Group Digest V93 #79
  499. To: tcp-group@ucsd.edu
  500.  
  501. Returned Mail: Could not find any To: or Cc: recipients.
  502.  
  503. *** Returned Mail Message Follows: ***
  504.  
  505. ------------------------------
  506.  
  507. Date: Sat, 27 Mar 93 04:30:06 PST
  508. From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
  509. Subject: TCP-Group Digest V93 #79
  510. To: tcp-group-digest@ucsd.edu
  511.  
  512. TCP-Group Digest            Sat, 27 Mar 93       Volume 93 : Issue   79
  513.  
  514. Today's Topics:
  515.                              3COM Sniffer
  516.               Anyone seen this problem before ? (2 msgs)
  517.          any System V release 3 ports of NOS/NET (KA9q)/slip
  518.                        AX25 and Linux (2 msgs)
  519.                               LAPB bugs
  520.                       Latest BPQ with IP Router
  521.                   TCP-Group Digest V93 #78 (2 msgs)
  522.  
  523. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  524. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  525. Problems you can't solve otherwise to brian@ucsd.edu.
  526.  
  527. Archives of past issues of the TCP-Group Digest are available
  528. (by FTP only) from UCSD.Edu in directory "mailarchives".
  529.  
  530. We trust that readers are intelligent enough to realize that all text
  531. herein consists of personal comments and does not represent the official
  532. policies or positions of any party.  Your mileage may vary.  So there.
  533. ----------------------------------------------------------------------
  534.  
  535. Date: Fri, 26 Mar 93 11:28:05 EST
  536. From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
  537. Subject: 3COM Sniffer
  538. To: tcp-group@ucsd.edu
  539.  
  540. I put the file eprobe.zip in the ucsd.edu incoming. It is a PUBLIC
  541. DOMAIN ethernet monitor program from 3COM for any of there ethernet
  542. board products. It is a nifty way to monitor ethernet traffic on a
  543. PC. It has filtering modes and detailed viewing.
  544.  
  545. I thought this might be of interest to the ampr group. If it is not
  546. appropriate to have it on here then take it off.
  547.  
  548. Doug
  549.  
  550. ------------------------------
  551.  
  552. Date: Fri, 26 Mar 93 10:10:09 CST
  553. From: andyw@aspen.cray.com (Andy Warner)
  554. Subject: Anyone seen this problem before ?
  555. To: tcp-group@ucsd.edu (TCP Group)
  556.  
  557. Has anyone seen NOS behave in the following way ?
  558.  
  559. An interface is set up to work in datagram mode, but sometimes
  560. NOS decides to start talking in VC mode (to just one or two
  561. stations, not everyone on that interface). If the remote
  562. station in question has jumpstart on, there's a timewasting
  563. round of "Huh?", "Huh?", "Huh?".... until one or other gets bored
  564. and drops the ax25 connection.
  565.  
  566. Things I know as facts :-
  567.  
  568. 1. I'm running a very recent version of KA9Q (not JNOS, PA0GRI etc),
  569.    with some local mods, they might be the culprit, but I thought
  570.    I'd ask.
  571.  
  572. 2. This has been going on for a while now, so the problem existed
  573.    with earlier NOS versions I used (PA0GRI based, I believe).
  574.  
  575. 3. It is definately my station that initiates the VC mode, (I send
  576.    the SABM).
  577.  
  578. Observations that may or may not be true :-
  579.  
  580. 1. I run a name server on my ethernet, and accesses by other stations
  581.    to the nameserver seem to cause the problem to occur most readily.
  582.    From the traces I have noticed that sometimes I will get an "ICMP
  583.    code port unreachable" when I issue a DNS reply, could this be that
  584.    NOS got bored waiting for my answer, and closed the port ?
  585.  
  586. 2. I've never seen this happen to a TCP connection, only to UDP traffic.
  587.  
  588. If this sounds familiar to anyone, or if you've got any ideas, send
  589. mail & I'll summarise. I hope to dive into the code this weekend...
  590. -- 
  591. andyw. N0REN/G1XRL
  592.  
  593. andyw@aspen.cray.com Andy Warner, Cray Research, Inc. (612) 683-5835
  594.  
  595. ------------------------------
  596.  
  597. Date: Fri, 26 Mar 1993 12:31:34 -0600 (CST)
  598. From: lcz@dptspd.sat.datapoint.com (Lee Ziegenhals)
  599. Subject: Anyone seen this problem before ?
  600. To: tcp-group@ucsd.edu (tcp/ip networking group)
  601.  
  602. >
  603. >Has anyone seen NOS behave in the following way ?
  604. >
  605. >An interface is set up to work in datagram mode, but sometimes
  606. >NOS decides to start talking in VC mode (to just one or two
  607.  
  608. Andy,
  609.  
  610. One thing that would cause this is for someone to send a datagram
  611. with the "reliability" flag set (0x04) in the IP TOS field.  JNOS will
  612. send such datagrams in VC mode, regardless of the default "ax25 mode"
  613. setting.
  614.  
  615. ------------------------------
  616.  
  617. Date: Fri, 26 Mar 93 16:34:58 CST
  618. From: "Erach A. Irani" <irani@cs.umn.edu>
  619. Subject: any System V release 3 ports of NOS/NET (KA9q)/slip
  620. To: tcp-group@ucsd.edu
  621.  
  622. --- If this is a repeat, please excuse me.  I still cannot locate a
  623. working implementation, and that seems highly unlikely to me ---
  624.  
  625. Hi,
  626.  I read that you have agreed to help out by being the
  627. coordinator for the UNIX ports.  have you heard of a sys 5 release 3
  628. port of nos/net ka9q slip WHICH can allow me to login to the
  629. originating machine and do UNIX'ish work (rather than talk alone).
  630.  
  631.  A limited number of logins is all I need.
  632.  Thanks,
  633.  erach
  634.  
  635. ------------------------------
  636.  
  637. Date: Fri, 26 Mar 93 08:22:10 CST
  638. From: Brian K. Teravskis <brian@smedley.telex.mn.org>
  639. Subject: AX25 and Linux
  640. To: tcp-group@ucsd.edu
  641.  
  642. Is anyone working on getting AX25 incorporated
  643. into the Linux kernel or is KA9Q the only way
  644. to go for now??
  645.  
  646. Thanks..
  647.  
  648. Brian
  649.  
  650. ------------------------------------------------------------------------------
  651. Brian K. Teravskis          |   Internet: brian@smedley.telex.mn.org
  652. Telex Communications, Inc   |             brian@hercules.vware.mn.org
  653. Bloomington, MN  55420      |   AMPRNET:  brian@hercules.wd0efl.tcman.ampr.org
  654. ------------------------------------------------------------------------------
  655.  
  656. ------------------------------
  657.  
  658. Date: Fri, 26 Mar 1993 09:50:10 -0800 (PST)
  659. From: Bruce Perens <bruce@pixar.com>
  660. Subject: AX25 and Linux
  661. To: "Brian K. Teravskis" <brian@smedley.telex.mn.org>
  662.  
  663. Right now, you must run a KA9Q variant such as WAMPES under Linux,
  664. because the various people who have been hacking in AX.25 drivers
  665. aren't ready to release them. We're waiting for the SLIP modifications
  666. to the kernel (mostly STREAMS support) to stabilize, as we want to use
  667. some of that to support AX.25. Also, the Linux TCP/IP implementation is
  668. still being debugged - the original developer has left the effort in a
  669. huff due to too much criticism, and others are now posting about one
  670. bug-fix a day. 
  671.  
  672. I find that running KA9Q under Linux is much more comfortable than
  673. running KA9Q on DOS, simply because of the multi-tasking - I can do
  674. something else with the computer while KA9Q is running, and if KA9Q
  675. dies it doesn't crash the system.
  676.  
  677. It is going to be nice when we can abandon the monolithic structure of
  678. NOS, and break the system into separate processes. I find it much easier
  679. to modify and debug that way.
  680.      Bruce Perens KD6OTD
  681.  
  682. On Fri, 26 Mar 1993, Brian K. Teravskis wrote:
  683.  
  684. > Is anyone working on getting AX25 incorporated
  685. > into the Linux kernel or is KA9Q the only way
  686. > to go for now??
  687. > 
  688. > Thanks..
  689. > 
  690. > Brian
  691. > 
  692. > ------------------------------------------------------------------------------
  693. > Brian K. Teravskis          |   Internet: brian@smedley.telex.mn.org
  694. > Telex Communications, Inc   |             brian@hercules.vware.mn.org
  695. > Bloomington, MN  55420      |   AMPRNET:  brian@hercules.wd0efl.tcman.ampr.org
  696. > ------------------------------------------------------------------------------
  697. > 
  698. > 
  699.  
  700. ------------------------------
  701.  
  702. Date: Fri, 26 Mar 93 14:29:55 PST
  703. From: psm%helios.nosc.mil@nosc.mil (Scot McIntosh)
  704. Subject: LAPB bugs
  705. To: tcp-group@ucsd.edu
  706.  
  707. Following are some bugs and deficiencies that I've found in the LAPB
  708. code, which a couple of group members have requested that I post.
  709. Excuse the extra-wide format. Hope it doesn't make this unreadable
  710. for some.
  711.  
  712. ------------------------------
  713.  
  714. Date: Fri, 26 Mar 93 19:04:03 GMT
  715. From: g4klx@g4klx.demon.co.uk (Jonathan Naylor)
  716. Subject: Latest BPQ with IP Router
  717. To: TCP-Group@ucsd.edu
  718.  
  719. On incoming as ucsd.edu is the latest version of G8BPQs switch software,
  720. BPQ406E.ZIP. In it is included the first release of his IP router software
  721. that operates as an application above the switch. It has been in beta testing
  722. for quite a while in our local packet area with good results. John has added
  723. a protocol for auto routing between his switches.
  724.  
  725. Could somebody move it from incoming to the g8bpq directory please.
  726.  
  727. John G8BPQ can now be reached at g8bpq@g4klx.demon.co.uk
  728.  
  729. 73's
  730.  
  731. Jonathan
  732.  
  733. ------------------------------
  734.  
  735. Date: Fri, 26 Mar 93 11:02:08 EST
  736. From: Postmaster@alis3.daytonoh.ncr.com
  737. Subject: TCP-Group Digest V93 #78
  738. To: tcp-group@ucsd.edu
  739.  
  740. Returned Mail: Could not find any To: or Cc: recipients.
  741.  
  742. *** Returned Mail Message Follows: ***
  743.  
  744. ------------------------------
  745.  
  746. Date: Fri, 26 Mar 93 04:30:11 PST
  747. From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
  748. Subject: TCP-Group Digest V93 #78
  749. To: tcp-group-digest@ucsd.edu
  750.  
  751. TCP-Group Digest            Fri, 26 Mar 93       Volume 93 : Issue   78
  752.  
  753. Today's Topics:
  754.                         New nos version PA0GRI
  755.  
  756. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  757. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  758. Problems you can't solve otherwise to brian@ucsd.edu.
  759.  
  760. Archives of past issues of the TCP-Group Digest are available
  761. (by FTP only) from UCSD.Edu in directory "mailarchives".
  762.  
  763. We trust that readers are intelligent enough to realize that all text
  764. herein consists of personal comments and does not represent the official
  765. policies or positions of any party.  Your mileage may vary.  So there.
  766. ----------------------------------------------------------------------
  767.  
  768. Date: Fri, 26 Mar 93 10:08:02 MET
  769. From: gvdg@tophat.cdh.cdc.com
  770. Subject: New nos version PA0GRI
  771. To: tcp-group@ucsd.edu
  772.  
  773. Hello All,
  774. Just before going i loaded my latest work on NOS onto ucsd.edu
  775. Main work lately was on tcp and ip access code. 
  776. The c command help display now correctly displays the possible commands
  777. for the various compile options of mailbox.c
  778. Now i am all set to get "lost" in the big lands and have a good time.
  779. >>For all who wrote me a message: I took all notes with me and use them
  780. as time and place comes by. Freq for simplex is 145.520 (i forgot the
  781. 30kc channel space.) Thanks all those responded , to nummerous to get back
  782. to individualy (sorry).
  783. Please have funn, i will.
  784. Regards, Gerard.
  785. -- 
  786. Internet: gvdg@cdc.com                  |     Gerard J van der Grinten
  787. UUCP:     gvdgpc!gvdg                   |     Control Data Bv.
  788. Telephone: 0(+31)-15-153123             |     Olaf Palmestraat 20
  789.                                         |     2616 LS DELFT    Netherlands
  790.  
  791. ------------------------------
  792.  
  793. End of TCP-Group Digest V93 #78
  794. ******************************
  795.  
  796. ------------------------------
  797.  
  798. Date: (null)
  799. From: (null)
  800.         Start
  801. File    Line       Function                        Description
  802.  
  803. lapb.c   168       lapb_input           The following code fragment is part of
  804. the processing for
  805.                                         the LAPB_CONNECTED state. 'control'
  806. contains
  807.                                         the complete control field from an
  808. incoming frame, which,
  809.                                         in the case of an RNR, has an N(R)
  810. field. Therefore, the 
  811.                                         control == RNR test fails when the N(R)
  812. field of the RNR
  813.                                         contains nonzero. Change 'control' to
  814. 'type' to fix this.
  815.  
  816.                                  case RR:
  817.                                  case RNR:
  818.                                   axp->flags.remotebusy = (control == RNR) ?
  819. YES : NO;
  820.                                   if(poll)
  821.                                    enq_resp(axp);
  822.                                   ackours(axp,nr);
  823.                                   break;
  824.  
  825. lapb.c  371        ackours              The ackours() function returns a -1
  826. value to cause a
  827.                                         FRMR if an acknowledgement is received
  828. for an unsent frame.
  829.                                         None of the routines calling ackours
  830. pays any attention to
  831.                                         the return value. Suggest modifying
  832. ackours to send the FRMR
  833.                                         itself:
  834.  
  835.                                         static int
  836.                                         ackours(axp,n)
  837.                                         struct ax25_cb *axp;
  838.                                         int16 n;
  839.                                         { 
  840.                                            struct mbuf *bp;
  841.                                            int acked = 0; /* Count of frames
  842. acked by this ACK */
  843.                                            int16 oldest; /* Seq number of
  844. oldest unacked I-frame */
  845.                                            int32 rtt,abserr;
  846.  
  847.                                            /* Free up acknowledged frames by
  848. purging frames from the I-frame
  849.                                             * transmit queue. Start at the
  850. remote end's last reported V(r)
  851.                                             * and keep going until we reach the
  852. new sequence number.
  853.                                             * If we try to free a null pointer,
  854.                                             * then we have a frame reject
  855. condition.
  856.                                             */
  857.                                             oldest = (axp->vs - axp->unack) &
  858. MMASK;
  859.                                             while(axp->unack != 0 && oldest !=
  860. n){
  861.                         >>                     if((bp = dequeue(&axp->txq)) ==
  862. NULLBUF){
  863.                         >>                 /* Acking unsent frame */
  864.                         >>                        sendfrmr(axp, axp->control,
  865. LAPB_RESPONSE, axp->pf, Z);
  866.                         >>                 return -1;
  867.                                              }
  868.  
  869.                                              Remainder of routine is same. The
  870. arguments to sendfrmr are
  871.                                              the offending packet's control and
  872. pf fields, an indication
  873.                                              that this is a response, and the
  874. reason for the FRMR.
  875.                                              Note: have to add 'control' and
  876.                                              'pf' fields to struct ax25_cb and
  877. fill them with the control
  878.                                              and pf fields of the offending
  879. incoming frame. Also, the X.25 
  880.                                              standard specifies that after
  881. sending an FRMR, the DCE enters into
  882.                                              a frame rejection condition and
  883. waits for a SABM, DISC, or DM
  884.                                              from the DTE (this is an
  885. abbreviated description of what the
  886.                                              standard really says). Suggest
  887. adding the LAPB_REJECT state 
  888.                                              and the processing for it in the
  889. lapb_input function, and have
  890.                                              the sendfrmr function invoke the
  891. LAPB_REJECT state. Also
  892.                                              suggest adding 
  893.  
  894.                                                   sendfrmr(axp, axp->control,
  895. LAPB_RESPONSE, axp->pf, W);
  896.  
  897.                                              for the cases where an incoming
  898. frame has a control field
  899.                                              containing an unknown type.
  900.  
  901.  
  902. lapb.c   various   lapb_input                The code decides whether the local
  903. station is busy by the
  904.                    enq_resp                  following means:
  905.  
  906.                                              if(len_p(axp->rxq) >= axp->window){
  907.                                                      /* Too bad he didn't
  908. listen to us; he'll
  909.                                                       * have to resend the
  910. frame later. This
  911.                                                       * drastic action is
  912. necessary to avoid
  913.                                                       * memory deadlock.
  914.                                                       */
  915.                                                      
  916. sendctl(axp,LAPB_RESPONSE,RNR | pf);
  917.  
  918.                                              _or_
  919.  
  920.                                              tmp = len_p(axp->rxq) >=
  921. axp->window ? RNR : RR;
  922.  
  923.                                              The len_p routine only determines
  924. the length of the 
  925.                                              packet at the front of the receive
  926. queue. If multiple
  927.                                              receive packets are queued, they
  928. aren't taken into
  929.                                              account in calculating whether the
  930. window has been
  931.                                              exceeded.
  932.  
  933. lapbtime.c 95      tx_enq                    The following code fragment is
  934. from the tx_enq routine:
  935.  
  936.                                               if(axp->txq != NULLBUF
  937.                                                && (len_p(axp->txq) <
  938. axp->pthresh || axp->proto == V1)){
  939.                                                /* Retransmit oldest unacked
  940. I-frame */
  941.                                               
  942. dup_p(&bp,axp->txq,0,len_p(axp->txq));
  943.                                                ctl = PF | I | (((axp->vs -
  944. axp->unack) & MMASK) << 1)
  945.                                                 | (axp->vr << 5);
  946.                                               
  947. sendframe(axp,LAPB_COMMAND,ctl,bp);
  948.                                               } else {
  949.                                                ctl = len_p(axp->rxq) >=
  950. axp->window ? RNR|PF : RR|PF; 
  951.                                                sendctl(axp,LAPB_COMMAND,ctl);
  952.                                               }
  953.  
  954.                                               A condition can arise wherein a
  955. transmit packet has been put on
  956.                                               axp->txq, but transmission not
  957. initiated because lapb_output()
  958.                                               found that axp->flags.remotebusy
  959. indicated that the remote station
  960.                                               is busy. In this case, if
  961. tx_enq() is called by recover() or
  962.                                               pollthem(), txq will be non-null,
  963. and the I frame could be transmitted.
  964.                                               This is incorrect behavior when
  965. the remote is busy. If by chance
  966.                                               the remote has become unbusy
  967. between the time of the lapb_output()
  968.                                               failure and the call to tx_enq(),
  969. the tx_enq() transmission of the
  970.                                               I frame doesn't increment
  971. axp->vs, and axp->unack is zero, so an
  972.                                               acknowledgement by the remote
  973. will not be processed properly by
  974.                                               ackours();
  975.  
  976. ------------------------------
  977.  
  978. End of TCP-Group Digest V93 #79
  979. ******************************
  980.  
  981. ------------------------------
  982.  
  983. End of TCP-Group Digest V93 #80
  984. ******************************
  985. ******************************
  986.